home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2848 < prev    next >
Encoding:
Text File  |  1996-08-05  |  6.7 KB  |  183 lines
  1. Path: sn.no!not-for-mail
  2. From: tbk@sn.no (Thore Bjerklund Karlsen)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Demo/game to OS frien
  5. Date: 6 Feb 1996 07:05:50 +0100
  6. Organization: SN Internett
  7. Message-ID: <4f6r3u$2db@sinsen.sn.no>
  8. NNTP-Posting-Host: sinsen.sn.no
  9. Mime-Version: 1.0
  10. Content-Type: text/plain; charset="iso-8859-1"
  11. Content-Transfer-Encoding: 8bit
  12.  
  13. (Michael van Elst)
  14.  
  15. >>>You are already dead at that point because you don't know how to
  16. >>>handle incoming interrupts.
  17.  
  18. >>What?!  Why not?
  19.  
  20. >Because you don't know how to control the hardware that is sending
  21. >interrupts. After all there _is_ hardware beyond the basic A1200, no ?
  22.  
  23. If  you code knowing that your program won't support gfx-cards, why not
  24. also assume it is a standard Amiga?
  25.  
  26. >>>Not more than when banging hardware. Well, maybe more because you
  27. >>>have more things you can do.
  28.  
  29. >>Not  more?   There are a zillion more things to take into consideratio
  30. >>when doing OS-programming.
  31.  
  32. >Same for hardware programming. But the real thing is that OS programmin
  33. >is much easier because usually you do NOT have to consider a zillion th
  34.  
  35. >If you want to hack around the OS _then_ you get into extra work.
  36.  
  37. No  you  don't.   If  you  stop  the OS, only your own code is running.
  38. Nothing to hack around.
  39.  
  40. >>Have you done any HW-programming at all?
  41. >>I have done both, and I know the difference.
  42.  
  43. >Well, I know that with HW programming (especially c0d3r style) you have
  44. >to think about much more.
  45.  
  46. How do you know that?
  47.  
  48. >>>Unfortunately not. Your simple description above is already CRAP.
  49.  
  50. >>Then tell me what's crap about it.
  51.  
  52. >Read my explanation about interrupts.
  53.  
  54. Please..   Pull the other one.  A VBLANK is defined as a VBLANK.  After
  55. a  Loadview(0)  it  should  be 50/60 frames a second.  If you assume an
  56. Amiga with native display, blitter and CIA should be there.  Well known
  57. hardware.
  58.  
  59. >>How  would  Turrican  2  be  using only the OS?  Shadow of the beast 3
  60. >>Somehow I doubt it could have been done with the OS.
  61.  
  62. >Maybe not exactly but pretty close.
  63.  
  64. How  about  full  gfx-card  supporting  code,  TOTALLY  system-friendly
  65. programming.  Would it still be "pretty close"?
  66.  
  67. >>A general PutPixel-routine IS slow, no matter if it
  68. >>is  your  own  or  the  OS-routine.  This has nothing to do with the O
  69. >>itself.
  70.  
  71. >Then why do you assume that you have to use it with the OS ?
  72.  
  73. Gfx-card  support?   That's the only reason I can see for using the OS.
  74. And that means using *only* the OS for gfx-rendering..
  75.  
  76. >>>Simply assuming things makes you chose the
  77. >>>wrong methods. Simply assuming things made you post the above
  78. >>>description how to take over the machine.
  79.  
  80. >>It has worked for me..
  81.  
  82. >Yes. That is the problem. You used it "because it has worked for you".
  83. >C0d3rz do these assumptions. If it works for them it must be correct.
  84. >That's why games have so many problems to run on anything else but
  85. >the basic A500 or A1200 hardware.
  86.  
  87. If it fails, it is shit code.
  88.  
  89. >>>Still rubbish. Even when you think it needs 100% of an A500 or A1200
  90. >>>it won't need 100% of an A4000.
  91.  
  92. >>Blitter speed doesn't improve with the A4000..
  93.  
  94. >So what ? There is more than just blitter operations in a game and peop
  95. >with graphics cards might even have a "blitter" that is much faster.
  96.  
  97. Yes,  but  what about those who have standard hardware?  Do you want to
  98. scroll  an  8bpl-screen  with  the  blitter  on those machines, because
  99. gfx-cards  don't support hardware-scrolling and copper-tricks needed to
  100. get fast scrolling?  Or will you just drop the idea of a fast scrolling
  101. game  altogether,  and make a 6-CD adventure game with rendered stills,
  102. because it can be made OS-compliant?
  103.  
  104. >>Yes,  because  the system can't even scroll a simple 1bpl screen in on
  105. >>frame on the A500.  Who wants a jerky game?
  106.  
  107. >Do you use PutPixel() to scroll ? Seems you are.
  108.  
  109. Oh, perhaps you're claiming there is another way of scrolling a screen?
  110. Load   your   favourite   text-viewer  and  scroll..   Jerk-jerk  on  a
  111. 68000-machine with KS2.x++.
  112.  
  113. >>Wonder  why  noone  tried.
  114.  
  115. >As you wrote: "That's  just  their  personality".
  116.  
  117. And I believe you answered something like:  "That's bullshit".
  118.  
  119. >>using the OS?  It surely can't be because all coders have big egos.
  120.  
  121. >That's the major reason.
  122.  
  123. Never thought this would happen, but..
  124.  
  125. "And  why  beholdest  thou  the  mote that is in thy brother's eye, but
  126. considerest  not  the  beam that is in thine own eye?  Or how wilt thou
  127. say  to  thy  brother,  Let me pull out the mote out of thine eye; and,
  128. behold, a beam is in thine own eye?  Thou hypocrite, first cast out the
  129. beam  out of thine own eye; and then shalt thou see clearly to cast out
  130. the mote out of thy brother's eye."
  131.  
  132. >>>>Oh,  I ignore machines that are more powerful? Nothing could be furt
  133. >>>>from the truth.
  134.  
  135. >>>Rubbish.
  136.  
  137. >>Why?
  138.  
  139. >Read above the section about interrupts. That's maybe not an impressive
  140. >example but it is a valid one.
  141.  
  142. So tell me which interrupt could be different from what I assume!
  143.  
  144. >>>I seriously believe that you do not care about compatibility.
  145. >>>If it runs for you (or with commercial background: for most of
  146. >>>the customers) it is enough.
  147.  
  148. >>Why would I want to code anything that only runs on my own machine?
  149.  
  150. >I don't know. But as it seems you are satisfied when it runs on your
  151. >machines. With your words: "It has worked for me".
  152.  
  153. My machines?╗It has run on *EVERY* machine I have *EVER* tested it on.
  154.  
  155. >>>Maybe it is not fast enough (which I don't believe and which is only
  156. >>>half of the story anyway). But the problem is that this argument come
  157. >>>independent of the hardware you do have which simply means that the
  158. >>>argument is wrong and you must have another reason.
  159.  
  160. >>Sorry, I don't really understand what you're trying to say here..
  161.  
  162. >The argument "not fast enough" comes independent of hardware. When c0d3
  163. >had A500s then hardware wasn't fast enough because not everyone had an 
  164. >(probably because 68020 were the fastest 68k CPU at that time).
  165. >Now that they have A1200s they reject using the system because not ever
  166. >had an 68040 (or 68060 since that was available).
  167. >So it doesn't matter what hardware they actually have because it would 
  168. >be "fast enough" in their argumentation. This is illogical and shows th
  169. >hardware speed has little influence on the c0d3rz decision to junk the 
  170. >system. They do it because the want to do it. Ideology, whatever. But s
  171. >the reason is not a technical one.
  172.  
  173. Hardware can't keep up with development, especially Amiga hardware.  If
  174. gfx-cards  were  standard, I would certainly use the system.  But it is
  175. too  damn  slow for graphics!  Run a 256-colour workbench on a standard
  176. Amiga chipset.  It's not a pretty sight!  IT IS SIMPLY NOT FAST ENOUGH!
  177. You *have* to use some tricks to get an acceptable result!
  178.  
  179. __
  180. \\\__ Thore B. Karlsen  % tbk@sn.no % C64-C128D-A1200-A2000C
  181.  \XX/ Wowbagger/AFL&SSN %  -c0d3r-  % A1230/50MHz-2C8F/340MB
  182.                                 
  183.